<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: ipc::shm::stl Namespace Reference</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;2.0.0</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Public API.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="namespaceipc.html">ipc</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1shm.html">shm</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1shm_1_1stl.html">stl</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="summary">
<a href="#nested-classes">Classes</a> &#124;
<a href="#func-members">Functions</a>  </div>
  <div class="headertitle"><div class="title">ipc::shm::stl Namespace Reference</div></div>
</div><!--header-->
<div class="contents">

<p><a class="el" href="namespaceipc_1_1shm.html" title="Modules for SHared Memory (SHM) support.">ipc::shm</a> sub-module providing integration between STL-compliant components (including containers) and SHared Memory (SHM) providers.  
<a href="namespaceipc_1_1shm_1_1stl.html#details">More...</a></p>
<table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="nested-classes" name="nested-classes"></a>
Classes</h2></td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1shm_1_1stl_1_1Arena__activator.html">Arena_activator</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">RAII-style class operating a stack-like notion of a the given <em>thread</em>'s currently active SHM-aware <code>Arena</code>, so that <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a> knows which <code>Arena</code> is currently active w/r/t a given code context operating on a SHM-stored container instance.  <a href="classipc_1_1shm_1_1stl_1_1Arena__activator.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in SHM in a given SHM-aware <code>Arena</code>.  <a href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="func-members" name="func-members"></a>
Functions</h2></td></tr>
<tr class="memitem:a96ccf3e4cf39d59d0a80e9026507b206"><td class="memTemplParams" colspan="2">template&lt;typename Arena , typename T1 , typename T2 &gt; </td></tr>
<tr class="memitem:a96ccf3e4cf39d59d0a80e9026507b206"><td class="memTemplItemLeft" align="right" valign="top">bool&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1shm_1_1stl.html#a96ccf3e4cf39d59d0a80e9026507b206">operator==</a> (const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T1, Arena &gt; &amp;val1, const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T2, Arena &gt; &amp;val2)</td></tr>
<tr class="memdesc:a96ccf3e4cf39d59d0a80e9026507b206"><td class="mdescLeft">&#160;</td><td class="mdescRight">Returns <code>true</code> for any 2 <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a></code>s managing the same <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html#ab8733c1237be93ee28664e4b983d535c" title="Short-hand for the Arena type this uses for allocation/deallocation/pointer semantics.">Stateless_allocator::Arena_obj</a>.  <a href="namespaceipc_1_1shm_1_1stl.html#a96ccf3e4cf39d59d0a80e9026507b206">More...</a><br /></td></tr>
<tr class="separator:a96ccf3e4cf39d59d0a80e9026507b206"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ab1b059d00a9cbdc54a917e051c1aecdf"><td class="memTemplParams" colspan="2">template&lt;typename Arena , typename T1 , typename T2 &gt; </td></tr>
<tr class="memitem:ab1b059d00a9cbdc54a917e051c1aecdf"><td class="memTemplItemLeft" align="right" valign="top">bool&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1shm_1_1stl.html#ab1b059d00a9cbdc54a917e051c1aecdf">operator!=</a> (const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T1, Arena &gt; &amp;val1, const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T2, Arena &gt; &amp;val2)</td></tr>
<tr class="memdesc:ab1b059d00a9cbdc54a917e051c1aecdf"><td class="mdescLeft">&#160;</td><td class="mdescRight">Returns <code>false</code> for any 2 <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a></code>s managing the same <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html#ab8733c1237be93ee28664e4b983d535c" title="Short-hand for the Arena type this uses for allocation/deallocation/pointer semantics.">Stateless_allocator::Arena_obj</a>.  <a href="namespaceipc_1_1shm_1_1stl.html#ab1b059d00a9cbdc54a917e051c1aecdf">More...</a><br /></td></tr>
<tr class="separator:ab1b059d00a9cbdc54a917e051c1aecdf"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table>
<a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2>
<div class="textblock"><p ><a class="el" href="namespaceipc_1_1shm.html" title="Modules for SHared Memory (SHM) support.">ipc::shm</a> sub-module providing integration between STL-compliant components (including containers) and SHared Memory (SHM) providers. </p>
<dl class="section note"><dt>Note</dt><dd>This sub-module/namespace is not limited to working with the jemalloc-based SHM provider supplied elsewhere in <a class="el" href="namespaceipc_1_1shm.html" title="Modules for SHared Memory (SHM) support.">ipc::shm</a>; it can and does work with any other SHM provider capable allocating an uninitialized buffer in SHM and later manually deallocating it by raw pointer. In fact, due to its simplicity of setup, the SHM-classic (a/k/a boost.interprocess) SHM provider (in <a class="el" href="namespaceipc_1_1shm_1_1classic.html" title="ipc::shm sub-module with the SHM-classic SHM-provider. See ipc::shm doc header for introduction.">ipc::shm::classic</a>) may be used in comments as the go-to example.</dd></dl>
<h3>Background</h3>
<p >What's this trying to do? Answer: It's quite a narrow purpose in fact, and it's important to separate it from orthogonal concerns to avoid confusion. So let's slowly explain step by step. Suppose we define as a bare-bones SHM provider via an <code>Arena</code> concept, where <code>Arena</code> is a class &ndash; instantiated in some unspecified way &ndash; with at least these key methods:</p>
<div class="fragment"><div class="line"><span class="keyword">class </span>Arena</div>
<div class="line">{</div>
<div class="line"><span class="keyword">public</span>:</div>
<div class="line">  <span class="comment">// Allocate uninitialized buffer of n bytes in this SHM arena; return locally-dereferenceable pointer</span></div>
<div class="line">  <span class="comment">// to that buffer.  Throw exception if ran out of resources.  (Some providers try hard to avoid this by</span></div>
<div class="line">  <span class="comment">// internally mapping more SHM pools, a/k/a mmap()ped areas, as needed.  However it is OK to throw:</span></div>
<div class="line">  <span class="comment">// e.g., an STL container might throw when trying to allocate something; such is life.)  Do not return</span></div>
<div class="line">  <span class="comment">// null.</span></div>
<div class="line">  <span class="keywordtype">void</span>* allocate(<span class="keywordtype">size_t</span> n);</div>
<div class="line"> </div>
<div class="line">  <span class="comment">// Undo allocate() that returned `p`; or the equivalent operation if the SHM provider allows</span></div>
<div class="line">  <span class="comment">// process 2 to deallocate something that was allocated by process 1 (and `p` indeed was allocated</span></div>
<div class="line">  <span class="comment">// in a different process but transmitted to the current process; and was properly made</span></div>
<div class="line">  <span class="comment">// locally-dereferenceable).</span></div>
<div class="line">  <span class="keywordtype">void</span> deallocate(<span class="keywordtype">void</span>* p);</div>
<div class="line">}</div>
</div><!-- fragment --><p >Suppose you have a plain-old-datatype (POD) type <code>T</code>; like an <code>int</code> or a <code>struct</code> with a bunch of scalars or arrays of scalars or various combos like that. To create an <code>T</code> in SHM, one could just call <code>Arena::allocate(sizeof(S))</code> and load it up with values based off the returned pointer, having cast it to <code>T*</code>. (Or one could use placement-construction but never mind.) To destroy it, one would <code>Arena::deallocate()</code> passing-in the returned pointer from <code>allocate()</code>. To transmit to another process, one would need to somehow send over a representation of <code>T* p</code>, then make it locally-dereferenceable, if the SHM-mapped vaddrs are not synced between the 2 processes.</p>
<p >Everything in the preceding paragraph is 100% orthogonal to <a class="el" href="namespaceipc_1_1shm_1_1stl.html" title="ipc::shm sub-module providing integration between STL-compliant components (including containers) and...">ipc::shm::stl</a>. That is not our problem. Now suppose <code>T</code> is not a POD but a bit more complex. Let's say it's <code>Vector&lt;E&gt;</code>, similar to <code>vector&lt;E&gt;</code>, with the usual semantics. Its internal representation would be very similar to:</p>
<div class="fragment"><div class="line"><span class="keyword">template</span>&lt;<span class="keyword">typename</span> E&gt; <span class="keyword">class </span>Vector</div>
<div class="line">{</div>
<div class="line"><span class="keyword">private</span>:</div>
<div class="line">  <span class="comment">// Currently allocated buffer starts at m_buf, is `m_buf_sz * sizeof(E)` long; and the used</span></div>
<div class="line">  <span class="comment">// range (within [0, size()) starts at m_buf also but is only m_elem_ct (&lt;= m_buf_sz) `E`s long.</span></div>
<div class="line">  E* m_buf; <span class="keywordtype">size_t</span> m_buf_sz; <span class="keywordtype">size_t</span> m_elem_ct;</div>
<div class="line">}</div>
<div class="line"><span class="keyword">using </span>T = Vector&lt;int&gt;;</div>
</div><!-- fragment --><p >Allocating a <code>T</code> itself works the same as before; but that would only allocate the outer layer &ndash; <code>sizeof(T)</code> &ndash; with those 3 data members themselves. But what happens when the <code>Vector</code> allocates into <code>m_buf</code>? A naive impl would just use <code>new</code>. But that wouldn't work if one tried to access the <code>T</code> in another process, even having acquired a locally-dereferenceable pointer to it (which is outside our scope completely; but doable as we established earlier): <code>m_buf</code> is never locally-dereferenceable in any process but the original one. One would have to somehow translate it and change <code>m_buf</code> to make it locally-dereferenceable; but then it would become wrong in the original process: remember that the idea is to place the <code>T</code> <em>itself</em> into SHM in the first place. One could write internal <code>Vector</code> code that would do the translation &ndash; essentially be SHM-aware &ndash; but that's terribly onerous a requirement for a container.</p>
<p >The good news is the STL containers, at least per standard and at least the <code>boost::container</code> impls of them, use a technique called <em>allocators</em> that resolves this problem (among others). So now consider <code>vector&lt;E&gt;</code>, namely an STL-standard-compliant implementation like <code>boost::container::vector</code> (and possibly your built-in <code>std::vector</code>, though that may or may not be fully STL-standard-compliant ironically). What it does essentially is:</p>
<div class="fragment"><div class="line"><span class="keyword">template</span>&lt;<span class="keyword">typename</span> E, <span class="keyword">typename</span> Allocator = std::allocator&lt;E&gt;&gt; <span class="keyword">class </span>Vector</div>
<div class="line">{</div>
<div class="line"><span class="keyword">private</span>:</div>
<div class="line">  Allocator m_alloc; <span class="comment">// Usually initialized via default-ct `Allocator()` at ctor time.</span></div>
<div class="line"> </div>
<div class="line">  <span class="comment">// Currently allocated buffer starts at m_buf, is `m_buf_sz * sizeof(E)` long; and the used</span></div>
<div class="line">  <span class="comment">// range (within [0, size()) starts at m_buf also but is only m_elem_ct (&lt;= m_buf_sz) `E`s long.</span></div>
<div class="line">  Allocator::pointer m_buf; <span class="keywordtype">size_t</span> m_buf_sz; <span class="keywordtype">size_t</span> m_elem_ct;</div>
<div class="line">}</div>
<div class="line"><span class="keyword">using </span>T = Vector&lt;int&gt;;</div>
</div><!-- fragment --><p >Firstly note the type of <code>m_buf</code>: it uses not a raw pointer but an allocator-type-driven type which must have certain pointer-like semantics. In <code>std::allocator</code>, it <em>is</em> simply the raw pointer <code>E*</code> after all; but for SHM we need to provide something else. Secondly, when it needs to allocate <code>m_buf</code>, it no longer does <code>new</code>. Instead it does basically <code>m_buf = m_alloc.allocate(sizeof(E) * m_buf_sz)</code>. And when deleting instead of <code>delete</code> it does <code>m_alloc.deallocate(p)</code>.</p>
<p >So via the allocator's (1) alloc/dealloc methods and (2) its mandated pointer type, the allocation strategy <em>and</em> pointer storage can be parameterized. As for <code>m_alloc</code> itself, it is often (usually) an empty object (<code>sizeof(Allocator) == 0</code>); that's a <em>stateless</em> allocator; and it is always default-cted. It can also be stateful (in which case it must be explicitly constructed). In real <code>vector</code> you'll see support for both.</p>
<p >How does this help our SHM use case? Firstly, of course, <code>allocate()</code> and <code>deallocate()</code> can be written to allocate/deallocate via <code>Arena::[de]allocate()</code>. Secondly, the <code>pointer</code> type can be something that, when stored in SHM, contains bits sufficient for its own methods, such as the dereference operator, compute the locally-dereferenceable location <code>void*</code> just from those bits, regardless of which process it's in. So in the case of SHM-classic, for example, <code>pointer</code> would be internally <code>bipc::offset_ptr&lt;E&gt;</code>, which uses a clever technique, namely storing inside the <code>offset_ptr</code> the offset compared to its own <code>this</code>. Remember this would be inside the same SHM pool, which is how the <code>classic</code> Arena works (it operates within one SHM pool).</p>
<p >Now: the <em>outside</em> allocation of <code>T</code> (<code>Vector&lt;E&gt;</code>) itself is done directly by the SHM <code>Arena</code> user. Once the STL-compliant container is involved, it does it indirectly via its <code>Allocator</code>. The same holds of deallocation: <em>outside</em> deallocation would invoke the <code>T::~T()</code> dtor first, which would then deallocate via <code>Allocator::deallocate()</code>; and then <code>Arena::deallocate()</code> the raw buffer (<code>sizeof(T)</code> long).</p>
<p >If <code>T</code> needs to allocate more objects that do yet more allocation on its behalf, then it would remember to propagate the <code>Allocator</code> to those, indefinitely. These <em>inside</em> allocations/deallocations/dereferencing all happen via <code>Allocator</code>. One must only only worry about invoking the ctor or dtor of <code>T</code> within the process that is indeed allowed to allocate/deallocate. (So if <code>Arena</code> does support deallocation in not-the-original-allocating process, then the dtor could be called in any process working with the <em>outside</em> <code>T</code>. If not, then not.)</p>
<h3>The task</h3>
<p >So that's the background. The main product of this namespace <a class="el" href="namespaceipc_1_1shm_1_1stl.html" title="ipc::shm sub-module providing integration between STL-compliant components (including containers) and...">ipc::shm::stl</a> is SHM-aware allocator types that can be used as template params to STL-compliant containers (and other types at times) in order to be able to allocate nested containers-of-containers...-of-PODs directly in SHM in such a way as to be accessible in multiple processes, as long as the <em>outside</em> <code>T*</code> is properly trasmitted from process to process by the user. Only the <em>outside</em> SHM handle to the container-of-... is something the user worries about; the rest "just works," as long as all containers involved are properly parameterized to use the SHM-aware allocator types we provide.</p>
<p >The main product, then, is <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. See its doc header. The short version for your convenience:</p><ul>
<li><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a> is itself parameterized on <code>Arena</code>, which must be a SHM-allocating type like the one used above. <code>Arena</code> must supply: <code>allocate()</code>, <code>deallocate()</code>, and <code>Pointer</code>. The <code>Pointer</code> must be a <em>fancy pointer</em> type that can produce a locally-dereferenceable <code>void*</code> and has data member(s) that contain bits that are process-agnostic (such as an offset, or pool ID and offset, and so on) when stored in SHM.<ul>
<li>In particular, <a class="el" href="classipc_1_1shm_1_1classic_1_1Pool__arena.html" title="A SHM-classic interface around a single SHM pool with allocation-algorithm services by boost....">classic::Pool_arena</a> complies with these requirements. Its allocate/deallocate work within 1 SHM pool per Arena. Its <code>Pointer</code> is internally <code>bipc::offset_ptr</code>.</li>
</ul>
</li>
<li><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a> is stateless. It is always default-cted, so all the user must do is remember to provide <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a> as the allocator template param(s) to the container type(s) involved. Therefore it must know which <code>Arena</code> it shall operate on. This is controlled on a thread-local basis via RAII-style helper <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Arena__activator.html" title="RAII-style class operating a stack-like notion of a the given thread&#39;s currently active SHM-aware Are...">Arena_activator</a></code>. (So the user must use <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Arena__activator.html" title="RAII-style class operating a stack-like notion of a the given thread&#39;s currently active SHM-aware Are...">Arena_activator</a> ctx(Arena*)</code> to activate the "current" Arena for the purposes of <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a> use, before any work with the STL-compliant container types involved in a given SHM-stored data structure.)</li>
</ul>
<p >As of this writing we just provide <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. <code>Stateful_allocator</code> may also be provided depending on need. It would not require the use of <a class="el" href="classipc_1_1shm_1_1stl_1_1Arena__activator.html" title="RAII-style class operating a stack-like notion of a the given thread&#39;s currently active SHM-aware Are...">Arena_activator</a> by the user; but then various difficulties inherent to working with stateful allocators come into force. (Just the fact extra bits per container instance are necessary to refer to the appropriate allocator object, which knows which <code>Arena</code> to operate-upon = not super-great.) </p>
</div><h2 class="groupheader">Function Documentation</h2>
<a id="ab1b059d00a9cbdc54a917e051c1aecdf" name="ab1b059d00a9cbdc54a917e051c1aecdf"></a>
<h2 class="memtitle"><span class="permalink"><a href="#ab1b059d00a9cbdc54a917e051c1aecdf">&#9670;&nbsp;</a></span>operator!=()</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Arena , typename T1 , typename T2 &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">bool operator!= </td>
          <td>(</td>
          <td class="paramtype">const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T1, Arena &gt; &amp;&#160;</td>
          <td class="paramname"><em>val1</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T2, Arena &gt; &amp;&#160;</td>
          <td class="paramname"><em>val2</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Returns <code>false</code> for any 2 <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a></code>s managing the same <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html#ab8733c1237be93ee28664e4b983d535c" title="Short-hand for the Arena type this uses for allocation/deallocation/pointer semantics.">Stateless_allocator::Arena_obj</a>. </p>
<p >This satisfies formal requirements of STL-compliant <code>Allocator</code> concept. See cppreference.com for those formal requirements. Since it's a stateless allocator, this always returns <code>false</code>.</p>
<dl class="tparams"><dt>Template Parameters</dt><dd>
  <table class="tparams">
    <tr><td class="paramname">Arena</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
    <tr><td class="paramname">T1</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
    <tr><td class="paramname">T2</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
  </table>
  </dd>
</dl>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">val1</td><td>An allocator. </td></tr>
    <tr><td class="paramname">val2</td><td>An allocator. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd>See above. </dd></dl>

</div>
</div>
<a id="a96ccf3e4cf39d59d0a80e9026507b206" name="a96ccf3e4cf39d59d0a80e9026507b206"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a96ccf3e4cf39d59d0a80e9026507b206">&#9670;&nbsp;</a></span>operator==()</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Arena , typename T1 , typename T2 &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">bool operator== </td>
          <td>(</td>
          <td class="paramtype">const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T1, Arena &gt; &amp;&#160;</td>
          <td class="paramname"><em>val1</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html">Stateless_allocator</a>&lt; T2, Arena &gt; &amp;&#160;</td>
          <td class="paramname"><em>val2</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Returns <code>true</code> for any 2 <code><a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a></code>s managing the same <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html#ab8733c1237be93ee28664e4b983d535c" title="Short-hand for the Arena type this uses for allocation/deallocation/pointer semantics.">Stateless_allocator::Arena_obj</a>. </p>
<p >This satisfies formal requirements of STL-compliant <code>Allocator</code> concept. See cppreference.com for those formal requirements. Since it's a stateless allocator, this always returns <code>true</code>.</p>
<dl class="tparams"><dt>Template Parameters</dt><dd>
  <table class="tparams">
    <tr><td class="paramname">Arena</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
    <tr><td class="paramname">T1</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
    <tr><td class="paramname">T2</td><td>See <a class="el" href="classipc_1_1shm_1_1stl_1_1Stateless__allocator.html" title="Stateless allocator usable with STL-compliant containers to store (or merely read) them directly in S...">Stateless_allocator</a>. </td></tr>
  </table>
  </dd>
</dl>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">val1</td><td>An allocator. </td></tr>
    <tr><td class="paramname">val2</td><td>An allocator. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd>See above. </dd></dl>

</div>
</div>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Apr 11 2025 20:02:23 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
